Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

std: Move the iterator param on FromIterator and Extendable to the method. #8490

Closed
wants to merge 2 commits into from

Conversation

huonw
Copy link
Member

@huonw huonw commented Aug 13, 2013

If they are on the trait then it is extremely annoying to use them as
generic parameters to a function, e.g. with the iterator param on the trait
itself, if one was to pass an Extendable to a function that filled it
either from a Range or a Map, one needs to write something
like:

fn foo<E: Extendable<int, Range<int>> +
          Extendable<int, Map<&'self int, int, VecIterator<int>>>
      (e: &mut E, ...) { ... }

since using a generic, i.e. foo<E: Extendable<int, I>, I: Iterator<int>>
means that foo takes 2 type parameters, and the caller has to specify them
(which doesn't work anyway, as they'll mismatch with the iterators used in
foo itself).

This patch changes it to:

fn foo<E: Extendable<int>>(e: &mut E, ...) { ... }

@huonw
Copy link
Member Author

huonw commented Aug 13, 2013

@thestinger r?

@thestinger
Copy link
Contributor

@huonw: r+, but it needs a rebase

huonw added 2 commits August 15, 2013 01:05
…indings.

A pattern like `foo @ Foo(Bar(*), _)` should be legal, even if `foo` moves,
since the subpatterns are purely structural.

Fixes rust-lang#3761.
…thod.

If they are on the trait then it is extremely annoying to use them as
generic parameters to a function, e.g. with the iterator param on the trait
itself, if one was to pass an Extendable<int> to a function that filled it
either from a Range or a Map<VecIterator>, one needs to write something
like:

    fn foo<E: Extendable<int, Range<int>> +
              Extendable<int, Map<&'self int, int, VecIterator<int>>>
          (e: &mut E, ...) { ... }

since using a generic, i.e. `foo<E: Extendable<int, I>, I: Iterator<int>>`
means that `foo` takes 2 type parameters, and the caller has to specify them
(which doesn't work anyway, as they'll mismatch with the iterators used in
`foo` itself).

This patch changes it to:

    fn foo<E: Extendable<int>>(e: &mut E, ...) { ... }
bors added a commit that referenced this pull request Aug 15, 2013

If they are on the trait then it is extremely annoying to use them as
generic parameters to a function, e.g. with the iterator param on the trait
itself, if one was to pass an Extendable<int> to a function that filled it
either from a Range or a Map<VecIterator>, one needs to write something
like:

    fn foo<E: Extendable<int, Range<int>> +
              Extendable<int, Map<&'self int, int, VecIterator<int>>>
          (e: &mut E, ...) { ... }

since using a generic, i.e. `foo<E: Extendable<int, I>, I: Iterator<int>>`
means that `foo` takes 2 type parameters, and the caller has to specify them
(which doesn't work anyway, as they'll mismatch with the iterators used in
`foo` itself).

This patch changes it to:

    fn foo<E: Extendable<int>>(e: &mut E, ...) { ... }
@bors bors closed this Aug 15, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants